home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970104-19970326 / 000178_news@columbia.edu _Mon Feb 3 08:00:59 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id IAA11053
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 3 Feb 1997 08:00:58 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id IAA18124
  7.     for kermit.misc@watsun; Mon, 3 Feb 1997 08:00:57 -0500 (EST)
  8. Path: news.columbia.edu!psinntp!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: K95 xfer works when FTP doesn't?????
  12. Message-ID: <1997Feb2.175835.93143@cc.usu.edu>
  13. Date: 2 Feb 97 17:58:35 MDT
  14. References: <32f2266f.55500445@199.1.22.49> <5cukr2$14t$1@apakabar.cc.columbia.edu>
  15. Organization: Utah State University
  16. Lines: 44
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:6525
  18.  
  19. In article <5cukr2$14t$1@apakabar.cc.columbia.edu>, jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
  20. > In article <32f2266f.55500445@199.1.22.49>,
  21. > Vincent Fatica <vefatica@syr.edu> wrote:
  22. > : Is there some profound difference between sending files via FTP vs. 
  23. > : via Kermit/TCPIP?
  24. > : 
  25. > : Here's what's happening: On a PPP connection with a provider called 
  26. > : servtech, whenever I try to upload via FTP from home to a site outside
  27. > : 
  28. > : servtech.com, it bogs right down to almost nothing (<100 cps). But I 
  29. > : can Kermit (via TCP/IP) the same file to the same host, on the same
  30. > : connection, at the expected 3000 cps. I don't get it. Kermit is just
  31. > : sending out TCPIP packets just like (?) FTP, isn't it? What might
  32. > : account for FTP being horribly slow when Kermit is working normally?
  33. > : 
  34. > : Also, I have been playing with a HTML server on my NT machine. It
  35. > : behaves like FTP when trying to send something out onto the internet
  36. > : ... god-awful slow.
  37. > 
  38. > This is only a guess, but it sounds like someone's TCP/IP implementation
  39. > of TCP flow control is bad.  FTP/HTTP send files by opening a socket and 
  40. > sending data without any data being sent back in response.  Therefore,
  41. > when the TCP window fills and data gets stopped, the restart signal is
  42. > not getting through or not getting sent.
  43. > 
  44. > Kermit transfers continuously send data in both directions.  Therefore,
  45. > the available window size is always being piggy backed on top of real 
  46. > data packets.
  47. > 
  48. > Sounds like someone is trashing TCP packets with 0 data.
  49. --------
  50.     Um, er, not really.
  51.     FTP and HTPP and Telnet and a big bunch of other well know applications
  52. all use TCP/IP for transport. TCP/IP is TCP over IP, with its own congestion 
  53. control techniques. There is no such thing as send and send and expect no 
  54. response. On average every second TCP data segment is ACK'd.
  55.  
  56.     Vincent didn't mention details about whose TCP/IP stack etc so 
  57. speculating is definitely limited here. Since it's not really our task to 
  58. decipher the FTP clients of other vendors I suggest you contact their Tech 
  59. Support group, and your ISP, and ask for words of wisdom. Before doing so 
  60. please triple check the modem setup to avoid XON/XOFF flow control (that's 
  61. fatal for TCP/IP) and instead use RTS/CTS hardware flow control.
  62.     Joe D.